1. Field of the Invention
The present invention pertains to wireless local area network (LAN) communications, and particularly to allocation of resources during an associated state transition for, e.g., an initial association or a handover.
2. Related Art and Other Considerations
A wireless local area network (LAN) typically has plural mobile terminals (MTs) and an Access Point (AP). The Access Point is typically an interface unit serving as the interface towards the fixed network (i.e. the link from the wireless network to the wired network). In many applications the purpose of the AP is mainly to administrate the air interface (e.g., allocate Medium Access Control [MAC] resources) and to make the MT's connection as similar to an ordinary cable connection as possible.
HIPERLAN Type 2 (H2) is a new standard for wireless LAN systems. HIPERLAN Type 2 (H2) is described in documentation such as the following: (1) ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions; and (2) ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 2 Radio Link Control sublayer. For HIPERLAN Type 2 (H2), the Medium Access Control (MAC) layer is a connection-oriented, reservation-based time division multiple access (TDMA) MAC layer.
In HIPERLAN Type 2 (H2), the Access Point (AP) is also called the central controller (CC) in order to generalize its functions, and to reflect the fact that the resource allocation responsibility does not necessarily have to be located in a node (such as an Access Point) which acts towards the network. Accordingly, irrespective of location, the central controller (CC) is herein sometimes referred to also as the “AP/CC”. As explained in more detail below, the central controller (CC) both administrates the MAC protocol and the allocation of resources inside it.
The central controller (CC) manages the MAC frame. The MAC frame is a fixed TDMA frame which always starts with a beacon (BCH) obtained from the AP/CC. The transmitted beacon serves, among other things, to point out certain time slots, e.g., RACH slots, which could be used for, e.g., initiating control signalling. The initiating of control signaling can involve, for example, the mobile terminal (MT) using RACH slots to send Resource Requests (RRs). The Resource Requests (RRs) serve to request UL traffic resources in the MAC frame to be used for control signals (e.g., RLC messages).
The central controller (CC) collects the Resource Requests (RRs) from one or more mobile terminals (MTs) comprising the wireless LAN and, based on the received/collected requests from all such MTs, allocates resources for both downlink (DL) and uplink (UL) traffic. The allocated resources include Dedicated Control Channels (DCCHs) for control data (e.g., control signals, such as the RLC signals) and (UDCHs) for user data. In general there are no differences between requesting resources for control signals compared to requesting resources for user data. The mobile terminal (MT) only requests for an amount of Long CHannels (LCHs). For more detailed description on logical & transport channels as well as their identifiers see ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, Chapter 5.
After allocating the resources, the central controller (CC) announces the allocations in the Frame Control Channel (FCCH). Such announcement and the Frame Control Channel (FCCH) are described in ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, Chapter 6.3.
Of particular interest is the control signaling (e.g., control signals) utilized either (1) to initially associate a mobile terminal (MT) with a CC/AP, or (2) to handover a mobile terminal (MT) to the CC/AP. In this regard, in either the initial association scenario or the handover scenario the mobile terminal (MT) transitions through a respective series of association states. The association states differ depending on whether an initial association scenario or a handover scenario is in effect. FIG. 1 shows an example of association states for an initial association scenario, in which the task is for the MT to as quickly as possible move from state MT_Disassociated_from_AP to state MT_Associated_to_AP, and also then on to state Associated_CL_Broadcast_Joined and state DUC_Established. These states are described in Chapters 5.1.1, 5.1.1, 5.1.5, and 5.3.1, respectively, of ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 2 Radio Link Control sublayer. FIG. 2 shows an example of association states for a handover scenario, in which the task is for the mobile terminal (MT) to as quickly as possible move from state MT_Associated_with_old_AP to state HO_Completed_to_new_AP, and also then on to state Associated CL Broadcast Joined and to state DUC Established. These states are described in Chapters 5.2.1.3, 5.2.1.3, 5.1.5, and 5.3.1, respectively of ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 2 Radio Link Control sublayer.
As part of the transition through these association states, the mobile terminal (MT) transmits a sequence of control signals (e.g., Radio Link Control [RLC] messages) to the central controller (CC). However, according to present convention, prior to sending each such control signal of the sequence the mobile terminal (MT) must request resources for sending the control signal. Moreover, according to current convention, the mobile terminal (MT) is only allowed to request resources corresponding to what is currently pending in its transmission buffers. The requested resources, e.g., the resources sought, include appropriate Dedicated Control Channel(s) (DCCH) in the MAC frame to be used for the control signal. The request for resources itself takes the form of a separate message from the mobile terminal (MT) to the central controller (CC), which typically uses a Random Access Channel (RACH). In other words, when no resources have been allocated by the central controller (CC), the mobile terminal (MT) must use the RACH in order to request new resources for the control signal.
For an initial association scenario (see FIG. 1), the mobile terminal (MT) decides for itself with which AP/CC to associate. The first association request to the AP/CC takes the form of a ASCH/RCH message RLC_MAC-ID_ASSIGN (see, ETSI TS 101 761-1 V1.2.1 HiperLAN Type 2 Data Link Control, Part 2 Radio Link Control sublayer, Chapter 5.1.1.2). At this juncture the MT is not known to the central controller (CC), and thus it can only use generally available contention slots (i.e. the RACH area). See, ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, Chapters 6.3.2.5 & 6.3.3. The purpose of the RLC_MAC-ID_ASSIGN message is only to obtain a MAC-ID in order to be able to initiate association & connections setup procedures. Association then also includes capabilities negotiations, start-of-encryption, authentication etc., as described, e.g., in ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 2 Radio Link Control sublayer, Chapter 5.1.1. Both association and connections setup procedures must be concluded before any user data exchange can take place, and any general resource allocations applied.
As soon as a MAC-ID has been obtained, the mobile terminal (MT) may start to request UL resources for a further one of its control signals in the sequence. But the MT is only allowed to request for resources corresponding to what is pending in its transmission buffers. See, e.g., ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, Chapter 6.3.2.8. In other words, the mobile terminal (MT) can not request for “general” UL resources″. As explained below, this constraint of requesting resources for a control signal only when information for the control signal is already in its transmission buffer(s) presents several problems for the mobile terminal (MT).
For every individual uplink control signal (e.g., UL RLC signal) which comprises one or more LCHs, the mobile terminal (MT) must: (1) Wait until the control signals [e.g., RLC message(s)] is/are prepared; (2) Send a Resource Request(RR) in the RACH to obtain UL resources for the LCHs; (3) Follow required procedures for accessing the RACH slots (e.g. exponential backoff in case of collisions); (4) Upon assuming a successfully transmitted Resource Request (the MT cannot definitively know promptly if a Resource Request was successful), await the coming UL allocation (for which delay also depends on the load of the central controller (CC) and its processing delay); and only then (5) transmit the control signal (e.g., RLC signal/message). Moreover, if any of the control signals are lost, each of steps (1) through (5) described above (e.g., the entire RLC function) will have to be repeated for the lost control signal.
It is generally the mobile terminal (MT) which takes the initiative to move towards the next sub-state during association and connections setup procedures by sending the next control signal (e.g., RLC message) in the sequence after successfully receiving acknowledgment of the previous. After responding to the RLC_MAC-ID_ASSIGN message, the mobile terminal (MT) can subsequently send, at appropriate successive times, the remainder of the control signals in the sequence. The identity and nature of such control signals depends on such things as, for example, the particular Convergence Layer (CL) and Application scenario. One non-limiting example of remaining control signals (taken from ETSI Draft TS 101 761-3 V0.c—Profile for Business environments, Chapters 5.2 and 5.4) are four particular association control signals and three particular connection setup control signals. The four particular association control signals are as follows: RLC_LINK_CAPABILITY (1 LCH); RLC_KEY_EXCHANGE_MT—1&—2(2 LCHs); RLC_AUTHENTICATION (the number of UL signals and the number of LCHs per signal depends on the selected authentication type); and RLC_INFO_TRANSFER (1 LCH). The three particular connection setup control signals are as follows: RLC_SETUP (1 LCH); RLC_CONNECT_ACK (1 LCH); RLC_CL_BROADCAST_JOIN (1 LCH). Thus, in the this example, the minimum number of needed LCH RLC signals in the uplink (UL) for concluding the association is at least seven. The actual number needed may increase due to lost RLC signals (which, as explained above, require RLC retransmissions). Only after concluding all of the above mentioned signal exchanges may the mobile terminal (MT) start to send and receive user data.
Handover in HIPERLAN/2 typically occurs when a mobile terminal (MT) moves within a H2 network domain as defined by NET-ID. The mechanisms to increase handover performance are, however, not limited to handovers only between two H2 service areas, but could also be applied to handovers from some other network interface to a H2 network.
From an Radio Link Control (RLC) point of view, a handover is very similar to the association procedures described above. A main difference is that the first contact with the new AP/CC is performed using a different message (RLC_HANDOVER_REQ). This RLC_HANDOVER_REQ message activates Access Point (AP) handover mechanisms for backbone communication with previous Access Points (APs) in order to, e.g., forward the MT's attributes, user data etc. After responding to the RLC_HANDOVER_REQ message, the mobile terminal (MT) can subsequently send, at appropriate successive times, the remainder of the control signals in the sequence. The identity and nature of such control signals depends on such things as, for example, the particular Convergence Layer (CL) and Application scenario. One non-limiting example of remaining control signals (taken from ETSI Draft TS 101 761-3 V0.c—Profile for Business environments, Chapters 5.2 and 5.4) are the four particular association control signals and three particular connection setup control signals described above in connection with the initial association scenario. Thus, in this example handover scenario (as in the initial association scenario for this example), the minimum number of needed LCH RLC signals in the uplink (UL) for concluding the handover is at least seven. The actual number needed may increase due to lost RLC signals (which, as explained above, require RLC retransmissions). Only after concluding all of the above mentioned signal exchanges may the mobile terminal (MT) start to send and receive user data.
For user data connections sent over the User Data Channel (UDCH), there are three modes of operation for allocation of resources. In a first mode, also known as the “basic type of allocation”, all requests for resources are performed dynamically as the data arrives. The requesting entity (e.g., the mobile terminal (MT)) is only allowed to request for resources corresponding to what is currently pending in its transmission buffers. When no resources are allocated by the central controller (CC) the requesting entity must use the RACH in order to request new resources.
A second mode of allocation of resources for user data connections is also known as the “fixed capacity agreement” mode. In the fixed capacity agreement mode, the requesting entity [e.g., the mobile terminal (MT)] and the central controller (CC) agree upon a fixed amount of resources to be allocated at certain time intervals for the user data. Additional resources can also continuously be requested in the same way as for the basic type of allocation mode.
A third mode of allocation of resources for user data connections is also known as the “fixed slot allocation” mode. In the fixed slot allocation mode, the requesting entity and the central controller (CC) agree upon fixed resource slots to be allocated in the MAC frames for the user data. Additional resources can also continuously be requested in the same way as for the basic type of allocation mode. The fixed slot allocation mode is described, e.g., in ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, chapter 6.3.4.
Which of the above user data resource allocation modes is to be used is negotiated between the central controller (CC) and the requesting entity during setup of the user data connections. The connection setup must thus be concluded before the requesting entity can start to request resources.
Thus, during state transition such as, e.g., during an initial association scenario or a handover scenario, no connection characteristics have yet been established. At the same time it is highly desirable to keep the time of pre-connection inactivity as short as possible. However, the sheer number of messages transmitted to request resources for control signals, and the control signals themselves, and the delay attending each such message, works against time efficiency.
In the above regard, both the initial association scenario and the handover scenario involve strict sequences of control signals in which one individual control signal exchange must be concluded before a subsequent control signal can be generated and stored in a transmission buffer of the requesting entity [e.g., the mobile terminal (MT)]. Further, and as also previously explained, since most of these control signal exchanges involve Long Channel (LCH) messages, a Resource Request message must in advance be sent using the RACH in order to procure and be granted resources (e.g., DCCH) for each control signal transmission. Having to generate a separate Resource Request message in this fashion adds at least one additional message per “useful” exchange, thereby increasing the time of inactivity. Moreover, since the RACH is a contention-based access channel, requesting resources will always involve a certain amount of uncertainty regarding whether the resource request will reach the central controller (CC). Random Access backoff mechanisms may thus come to add even more delay and then also increase the period of inactivity.
FIG. 3 illustrates the foregoing, and particularly the fact that presently in a HIPERLAN 2 wireless LAN the MT experiences delays for each attempt to transmit an UL signal containing LCHs. In FIG. 3, Td is the added delay per signal, mainly introduced because the MT must use the RACH for Resource Requests in order to obtain UL resources. More accurately, Td is defined by Expression 1:Td=RACH_Delay+AP/CC—RR_Proc_delay  Expression 1:
In Expression 1, RACH_Delay is mainly due to two factors. The first factor is collisions with other contenders. When a collision is detected by the MT (see ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, Chapter 6.2.3), the MT is required to enter an exponential backoff scheme before trying again (see, ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, Chapter 6.3.3). The second factor is the delay added when a Resource Request is wrongly assumed as successfully transmitted. The MT must then realize for itself that a retransmission needs to be performed [concluded when no UL allocation is announced by the central controller (CC)]. The MT is not aware of the processing delays of the central controller (CC), and there are some rules preventing too aggressive behaviour of the MT (see, ETSI TS 101 761-1 V1.2.1—HiperLAN Type 2 Data Link Control, Part 1 Basic Data Transport Functions, Chapter 6.3.2.8).
In Expression 1, AP/CC_RR_Proc delay is the delay from correctly received RR in the AP/CC until an allocation is reserved and announced.
The delay Td applies to each control signal (e.g., each RLC signal transmission attempt) individually. Accordingly, the total resulting added delay for a sequence of control signals will be the accumulation of the individual delays, such accumulation being shown as Tdtot in Expression 2 and understood with respect to FIG. 4.Tdtot=Td1+Td2+ . . . +Tdn.  Expression 2
The total association delay TA is provided by Expression 3.TA=T—RLC_Processing+Tdtot  Expression 3
In Expression 3, T_RLC_Processing is the time needed for processing of the information contents of the RLC messages.
Thus, the accumulation of the individual delays involved in using the RACH in order to request resources for each control signal (e.g., each RLC message), in serial fashion, significantly lengths the inactivity period involved in an initial association scenario or a handover scenario in a wireless LAN system.
What is needed, therefore, and an object of the present invention, is a technique for reducing the time required to perform an association operation between a requesting entity and a central controller (CC) of a wireless LAN.